The method should return true only if the app is "handling the situation", but there is no guarantee that the app is handling the situation just by having listeners as the listeners are an array of any WebView listeners, not just the onRenderProcessGone listeners, so it could have a listener for other events and not for onRenderProcessGone.
In fact there is a bug in all the webViewListeners checks since they are never null but an empty ArrayList.
I think that could be fixed by changing the return of onRenderProcessGone from the WebViewListener to boolean and check if any of the listeners returned true.

What's the plan for handling the onRenderProcessGone on portals side? could we handle it in Capacitor so portals doesn't have to?

There is an alternate plugin PR where the handling is forwarded to plugins and they can return true if they are handling onRenderProcessGone instead of using listeners. That's similar to how we handle shouldOverrideLoad

Also, as an alternative if this is going to be a portals only thing, portals could use their own WebViewClient that extends BridgeWebViewClient and implements onRenderProcessGone and that would require no changes in Capacitor.

@jcesarmobile I like the solution in #6416 but it only provides access to that one specific WebViewClient method on the Plugin class, when the plugin could in theory just call addWebViewListener on the Bridge as well

Im tweaking the solution in this PR to give more control over the true/false return state

@jcesarmobile also in regards to this

What's the plan for handling the onRenderProcessGone on portals side? could we handle it in Capacitor so portals doesn't have to?

I was thinking about this. In Portals we need to give people full control since we don't know how the WebView is being used in an app, but in Capacitor right now I assume this is just an app crash. This is product decision but it might be nice if an error dialog displays and reloads the activity automatically or something.

@jcesarmobile I like the solution in #6416 but it only provides access to that one specific WebViewClient method on the Plugin class, when the plugin could in theory just call addWebViewListener on the Bridge as well

capacitor/android/capacitor/src/main/java/com/getcapacitor/Bridge.java

Line 1405 in 7e7c8b9

public void addWebViewListener(WebViewListener webViewListener) {

and use anything in the interface as well as onRenderProcessGone if it is added there. That WebViewListener can be used in plugins too.
Im tweaking the solution in this PR to give more control over the true/false return state

I'm just showing an alternative, which is similar to how the shouldOverrideUrlLoading event was handled, which is previous to the WebViewListener implementation, and shouldOverrideUrlLoading is not exposed on the WebViewListener.

At the moment all the WebViewListener expose methods that return void, while the shouldOverrideUrlLoading is the one returning a boolean and it's implemented in a different way. And onRenderProcessGone returns boolean, so might make sense to do it like shouldOverrideUrlLoading.
But it's also doable to make the WebViewListener return a boolean as demonstrated in your PR.

I have no preference on one over the other, probably makes sense to do all of them the same way.